FishMarket 1.0/FishMarket v1.0.iso/fishies/476-500/disk_496/memmometer/mm.doc

Text File | 1992-05-06 | 21KB | 340 lines

/*
 *   Information for MM Version 2.20, 19-May-1991
 *
 *   MemMometer - A program hacked from Tom Rokicki's WFrags more or less...
 *   (in fact, a heck of a lot) in the style of Peter Da Silva's "Gauge."
 *   The program opens a narrow window with the same dimensions as the disk
 *   capacity gadget found in the top-level workbench window for an Amiga
 *   DOS v1.3 floppy volume.  The sizing gadget is like the one in Gauge;
 *   to resize the window, just click the left mouse button over the "E".
 *   The "F" is the program title in this rather short manifestation of
 *   an Amiga Intuition window drag bar.
 *
 *   My bin copy of Gauge broke when I put a Michigan Insider in my A1000.
 *   I did not have source for the Gauge program, so I conjured this one.
 *   To my chagrin, MM 1.0 broke when I got a 2000 (more on that shortly),
 *   the Amiga 3000 blew away the previous version of this program, too,
 *   of course.  But that's the way it is with hardware-oriented software
 *   hacks! :-|  Changes with this version involve reconstruction of the
 *   fast ram address menus to accomodate the A3000's 32-bit address space
 *   for fast ram at 7000000 to 7FFFFFF hex.  Please note that Amiga DOS
 *   allocates this space in heap fashion (autoconfiguring memory in
 *   successively lower addresses starting from the top, while utilizing
 *   it within each zone in the usual fashion from the bottom up).  The
 *   following table describes how to set MM for various Amiga 3000 memory
 *   configurations:
 *                          Fast Ram Size    Base Address
 *                              1 Meg           7f00000
 *                              2 Meg           7e00000
 *                              3 Meg           7d00000
 *                              4 Meg           7c00000
 *                              6 Meg           7a00000
 *                              8 Meg           7800000
 *                             10 Meg           7600000
 *                             12 Meg           7400000
 *                             14 Meg           7200000
 *                             16 Meg           7000000
 *
 *   MemMometer may be started from an icon, a CLI, or the Run command
 *   from a CLI.  MM uses dynamic allocation for its display data, and
 *   does its own resource tracking.  MM will surrender any resources
 *   which it has successfully obtained from allocation requests if,
 *   while MM is running, requested resources are denied.  This type
 *   of fault (exit code 20) proceeds silently, and without prior notice.
 *
 *   Now for a run through MemMometer's menu mechanics.  MemMometer opens
 *   with a non-interlaced-screen-height narrow window at the left side of
 *   the Workbench screen.  The window width is the same as the width of the
 *   capacity gauge which Workbench used to render at the left side of the
 *   v1.3 top level window for a floppy volume.  As with Peter Da Silva's
 *   original gauge program, the MemMometer has an E at the bottom of the
 *   window, and an F at the top.
 *
 *   The E and the F are respectively, the window sizing gadget, and the
 *   window titlebar.  While MemMometer can and does automatically arrange
 *   the window to suit the memory configuration, it depends on the user to
 *   select appropriate memory size and address values via the menus.  The
 *   menu style is the usual Amiga Intuition menu set; selection is achieved
 *   by clicking the left mouse button while the mouse pointer is anywhere
 *   within the program's window boundary, and then activating the menu bar
 *   by holding down the right mouse button and sliding the mouse pointer
 *   along the Workbench screen title bar at the top of the Workbench screen.
 *
 *   At the left side of the Workbench screen title is the Project Menu.  The
 *   Project Menu has three options.  The first option is "Front", which is a
 *   window-to-front command for the event that the MM window was partially
 *   buried by the opening of new windows after MM was invoked.   If the
 *   right mouse button is released while the mouse pointer is directly over
 *   the Front menu item, the MM window will oblige by popping forward to an
 *   unobstructed view.  The second menu option is the "Back" item, which
 *   will move the MM window back behind any other windows that have been
 *   opened on the Workbench screen (with exception of a backdrop window).
 *   The third Project menu option is the "Quit" option, which directs MM to
 *   close its window and release the AmigaDOS resources it has allocated.
 *   The normal return code is zero.
 *
 *   The second Intuition menu is the Setup menu.  There are two Setup menu
 *   items.  The first item is the "Mode" item.  MM has two modes, and they
 *   are selected by sliding the mouse pointer straight down from the screen
 *   title bar over the Mode item , and then moving the pointer to the right
 *   as the mode submenu is activated.  The activated submenu provides two
 *   choices, "Frags" and "Warps".  Frags are rather much the same as they
 *   were in Da Silva's gauge program.  "Frags" is the default menu selection
 *   with which MM is first initialized.  The Frags display is described in
 *   the following table:
 *
 *               2-Color Workbench    4-Color Workbench    8-Color Workbench
 *  Unallocated        Blue                 Black                Black
 *  Allocated          White                Orange               Yellow
 *  Fragmented         Blue                 Blue                 Blue
 *
 *   Unallocated memory is free memory available to programs.  The programs
 *   may obtain this memory from AmigaDOS through allocation requests.  The
 *   Allocated memory is memory assigned to programs running under AmigaDOS.
 *   Fragmented memory consists of interleaved small memhunks, some of which
 *   are assigned to programs and some of which are in the free memory pool.
 *   The smallest fragments are 8 bytes, and the largest memhunks may be more
 *   than a megabyte.  The fragmented class is assigned when, in making the
 *   MM window display, a single horizontal pixel line was found to represent
 *   both allocated and unallocated memhunks.  For this reason, for a full
 *   window height MemMometer, the resolution of the fragmentation is shown
 *   in more detail on interlaced Amiga Workbench screens.
 *
 *   The second mode item selection is the "Warps" mode.  While the Frags
 *   mode is usually utilized as a low-priority background indicator, the
 *   Warps mode is usually utilized at a somewhat higher priority for the
 *   purpose of tracking bugs and system irregularities.  In this context,
 *   I define warps as a form of discretized sample-to-sample differencing
 *   function for some arbitrary segment of memory.  Warps are determined by
 *   dividing the selected address space evenly among the MemMometer display
 *   pixels, computing an assignment checkfunction for each pixel line of the
 *   display on the associated assigned memory space at some sample time, and
 *   then, while retaining the previous pixel-by-pixel record, repeating the
 *   same evaluation the second sample time and comparing the sequentially
 *   determined checksums. A "checksum" is computed by means of a sequential
 *   bit-wise eXclusive OR assignment.  This type of checksum can readily
 *   detect zeroed or changed values.  In the table below, logical FALSE is
 *   zero, logical TRUE is taken as 0xffffffff and VALUE is anything else.
 *   Colors indicate the type of change.  Colors for the most part follow
 *   the v1.3 standard CBM workbench color set; they're shown as follows:
 *
 *                    Pen #   Color           Pen #   Color
 *                      0     Blue              4     Green
 *                      1     White             5     Red
 *                      2     Black             6     Cyan
 *                      3     Orange            7     Yellow
 *
 *   These colors are used to map the changes in memory content from sample
 *   to sample as programs multitask together:
 *
 *   Condition        2-Color Workbench  4-Color Workbench  8-Color Workbench
 *
 *   VALUE ===> VALUE         Blue               Blue               Blue
 *   VALUE =/=> VALUE         White              Orange             Orange
 *   FALSE ===> FALSE         Blue               Black              Black
 *   FALSE ---> VALUE         White              Orange             Yellow
 *   VALUE ---> FALSE         White              White              Red
 *   TRUE  ---> FALSE         Blue               Black              Cyan
 *   TRUE  ---> VALUE         Blue               Black              Cyan
 *   TRUE  ===> TRUE          Blue               Blue               Green
 *   FALSE ---> TRUE          Blue               Blue               Green
 *   VALUE ---> TRUE          Blue               Blue               Green
 *
 *   The second Setup menu item is a Frequency selection submenu.  While the
 *   selected value does set a minimum frequency with which the memory state
 *   will be examined, it's done by introducing a delay between measurements.
 *   The introduced delay will be equal in seconds to the value selected in
 *   the submenu.  The delay is accomplished by the AmigaDOS timer.device
 *   using the VBLANK mode.  It was not thought worth the difficulty to make
 *   the timing as precise as would be possible using the cia.resource, as
 *   that might make the resource less useful to other programs, and as well
 *   would mean extra effort adjusting for memory size-dependent scan times
 *   from the various memory sizes selectable with the MM program.  Delay
 *   intervals of 1, 2, 5, and 10 seconds are available.
 *
 *   The third Intuition menu is a Priority menu.  This menu applies only to
 *   the MemMometer program and its associated CLI process.  Initially it is
 *   at priority 0 with the expectation that the user will set it lower once
 *   the program is running, in order to give more time to the other active
 *   processes the user will be running.  A value of -50 is recommended.  In
 *   the event the Priority of MM is changed via the menu, the CLI inherits
 *   MemMometer's new priority and retains that priority even after MM quits.
 *   Thus, with extreme priority settings, it may be better to "Run MM" to
 *   keep from passing the extreme priority to subsequent processes spawned
 *   from the CLI that was used to invoke MemMometer.  Also, go easy with the
 *   positive priorities; remember that with AmigaDOS version 2.0 the DOS
 *   input.device runs priority 20, the SCSI bus handler is 12, SCSI.device
 *   is 11,  FileSystem is priority 10, and the CON: and trackdisk.device
 *   are priority 5 usually.  Note that the first three MemMometer menu
 *   items are used to increment or decrement a priority selected in the
 *   lower part of the menu.  Selection of the "NORM" menu item removes any
 *   increment or decrement previously set while at any given level.
 *
 *   The remaining Intuition menu selections are provided so that the range
 *   and base address of the memory examined may be adjusted for the user's
 *   Amiga memory configuration.  Note that the base address must always be
 *   set to the correct base address for the given memory configuration in
 *   order for the Frags option to work properly, but that the range may be
 *   adjusted to give a better resolution for the first segments around the
 *   base address, if desired.  Menus are provided for Chip memory, the old
 *   Slow-Fast (C00000/Ranger) memory, and Fast memory.  While I have had no
 *   difficulty as a result of selecting a range of memory that involved a
 *   non-existent seqment for Chip or Fast memory in either Frags or Warps
 *   mode, when I selected non-existent SFMemory on my Fat Agnus Amiga 2000
 *   in Warps mode, it resulted in a total system-wide red Guru 4 (illegal
 *   instruction exception).
 *
 *   After that, I decided to post a requester for the user to issue terse
 *   warning that a crash is _possible_ with incorrectly specified menu
 *   selections in warps mode.  Since it is possible, for example, to roll
 *   over on 24-bit addresses via large memory size menu selections, one
 *   can access forbidden zones through inappropriate settings of the Fast
 *   Mem menus as well.  Thus MM also calls the requester if the Fast Mem
 *   size menu is changed. The requester displays the message:
 *
 *                        WARNING! CRASH POSSIBLE
 *                      MENU MEMORY SELECTIONS MUST
 *                       REFERENCE EXISTING MEMORY
 *
 *                   Risk It                  Retreat
 *
 *   You don't have to worry about a crash if you really have an amount of
 *   SF or Fast memory equal or greater than the amount you specified and
 *   the base address is within what you specified (the default base address
 *   for SF Mem is C00000 and 200000 for A2000 Fast Mem).  Too bad I have to
 *   do this, but it is a matter the hardware regards seriously, as some
 *   registers do things when they are read, never mind what they do when
 *   they are written!  If you really want to be annoyed, just get Bryce
 *   Nesbitt's Enforcer program.  It will yap at you through the serial port
 *   every time any program (such as this one) reads the zero page...
 *
 *   So, here you see the two options.  The left button says - Risk It -.
 *   That's a comfortable gamble if you know your Fast memory configuration.
 *   Pre Fat-Agnus Amiga 2000 machines have 512K of Slow-Fast memory.  The
 *   Newer 2000s have no C00000 Slow Fast memory, and the A3000 only has the
 *   200000 ZorroII 16-bit Fast Memory if you added a Mem card - so beware
 *   of this and try the other settings when you have nothing else going on,
 *   until you gain a knowledge of what is safe.  The - Retreat - option sets
 *   the SF or Fast Memory Size selected internal to the MemMometer program
 *   to zero and clears the display.  (It does leave the menu items checked,
 *   though, so you will have to remember to re-select suitable menu values
 *   in order to get the display to show something in each existing memory
 *   type.  For Chip and Fast memory this will simply entail going back into
 *   the menu and again selecting whatever was previously checked.  The SF
 *   memory size should be set either to appropriate values or to "NONE".)
 *
 *   Note that in the display there may at any time be anywhere from one
 *   to three MemMometers - for Chip (left-hand column), another for the
 *   Slow Fast mem (center column) and yet another for Fast mem (right-hand
 *   column).  These MemMometers can be turned on or off as desired by
 *   selecting "NONE" or the various items in the Size menus.
 *
 *   Parts of several freely distributable  programs have been used to make
 *   MemMometer.  Menus, for instance, are done in the style VT100 (Wecker,
 *   et al).  As with the VT100 program, MemMometer has preset variables.
 *   However, the program does not yet contain a script file reader or an
 *   AREXX interface with which to automatically set the variables.  Likely
 *   it is that I'll write the code for that some time this century!
 *
 *   MemMometer uses forbid() and permit() when it examines the mem list in
 *   Frags mode.  I suppose it is possible with large amounts of memory to
 *   scan, that some gross treachery can happen while the list is locked.
 *   However, with my 4 meg Amiga 3000 I've not seen it.  It takes a while
 *   after startup to settle out and display the large byte counts associated
 *   with Fast mem, so be patient...  MemMometer is most useful for finding
 *   out why large programs won't load.  It's also useful in development for
 *   seeing the impact your application is having on memory fragmentation,
 *   or how various programs (and viruses, for that matter) are allocating
 *   memory.
 *
 *   The Warps mode displays any change it sees in memory from one sample
 *   to the next; BUT this mode only works sensibly when JUST ONE memory size
 *   selection is active (set others to "NONE").  The memory space is scanned
 *   asynchronously, so it can have sample alias difficulties.  However, the
 *   Warps mode does not use forbid(), permit(), enable(), disable(), or any
 *   other constrictive system call.  It just does a lot of read-only memory
 *   cycles and writes the result in its own dynamically allocated memory
 *   space.
 *
 *   To run MemMometer, simply type
 *
 *      run MM
 *
 *      or  click on the icon.
 *
 *   Then open the menu item selections and set them for your configuration.
 *   Frags mode, and 512K of CHIP @0 is the default these days, what with
 *   hugh variety of configurations routinely encountered.  The modes are
 *   are color coded into the "F" and "E" indicators in accordance with the
 *   AmigaDOS v1.3 color table; AmigaDOS v2.0 looks pale by comparison:
 *
 *   Mode       Indicator       2 color WB      4 Color WB      8 Color WB
 *
 *   Frags          E                Blue            Blue            Blue
 *   Warps          E                White           Orange          Yellow
 *
 *   One column:
 *   Chip           F                Blue            Blue            Blue
 *   Slow-Fast      F                Blue            Black           Cyan
 *   Fast           F                White           Orange          Yellow
 *
 *   Two columns:
 *   Chip +SF       F                Blue            Blue            Blue
 *   Chip +Fast     F                Blue            Black           Cyan
 *   SF + Fast      F                White           Orange          Yellow
 *
 *   Three columns:
 *   C + SF + Fast  F                Blue            Blue            Blue
 *   None           F                White           Orange          Orange
 *
 *   The source code included with this distribution was compiled with the
 *   Manx Aztec C compiler, version 3.6a in 16-bit integer mode.  Numerous
 *   type casts in the code, as well as other non-alignments with the Lattice
 *   environment would make compilation under versions of Lattice difficult.
 *   Sorry.  Compilation instructions are of course in the makefile included
 *   in the distribution.
 *
 *   About my part of C code - it wasn't done for speed, as I am sure you can
 *   tell.  If I wanted speed I would have used assembly language.  It also
 *   likely isn't elegant code, by a long shot (unless it's the part I got
 *   from Rokicki's WFrags).  But assembly language is time-consuming to
 *   write, so that won't happen any time soon.  Maybe the next thing will be
 *   the AREXX port - so that other programs can specify a low address and a
 *   byte count range for one of the MemMometers to display (say, within the
 *   specified menu selection span).  Gross comments about the code or bug
 *   reports may be e-mailed to me at the site domain specified below.
 *
 *   About everyone else's C code in MM - Let's see, VT100 (Wecker et al) has
 *   been freely distributable since the early days of the Amiga.  When VT100
 *   was first posted, Wecker did not prepend a copyright to the code.  He
 *   later discovered that his employer (DEC) routinely required employees to
 *   sign a contract statement which granted to DEC all rights with respect
 *   to codes written by DEC employees, whether the codes were written on the
 *   company's time/facilities or otherwise.  I do not know how the matter
 *   was resolved, but VT100 still seems to be on the freely distributable
 *   software list.  The menus in MM, while styled with the same code forms
 *   as were used with VT100 v2.3, are of course different in content in any
 *   case.  The WFrags program was, I believe, a version by Tom Rokicki (the
 *   Amiga Tex guy) might be evolved from the Frags program originally put
 *   to the net by Mike Meyer.  WFrags was submitted to the net without a
 *   prepended copyright notice, evidently intended  as freely distributable
 *   software.
 *
 *   The spirit of these contributions is that they are not to be used for
 *   commercial purposes, and the original authors certainly appreciate
 *   being cited for their work.  So I just did that.  The timer codes are
 *   exerpted from a network article by Andy Finkel of CBM, submitted as a
 *   demonstration of the ease of implementing the Amiga timer.device in C.
 *
 *   So, for my part, I add no further restrictions to the codes in MM.
 *   In that spirit, I hereby submit the following Standard Disclaimer:
 *
 *   The authors accept no responsibility for anything either beneficial or
 *   detrimental that may happen as a result of using the codes in MM.  The
 *   codes are intended for non-commercial use only.
 *
 *
 *   Howard Hull  [e-mail]
 *
 */